home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / pc / XMODEM.ZIP / xmodem1k.txt < prev    next >
Encoding:
Text File  |  1996-03-06  |  4.6 KB  |  110 lines
  1. Perception presents:
  2. ---------- Understanding The X-Modem 1K File Transfer Protocol --------------
  3.  
  4.                   by Em Decay
  5.  
  6. This has to be one of the most internationally accepted protocols for upload-
  7.  ing and downloading binary and text files.  It is fairly straight-forward as
  8.  to how it is set up and there are fairly good error checking capablities.
  9.  
  10.  
  11. --- Before you begin ---
  12.  
  13. Look at my XMODEM.TXT and XMODEMCRC.TXT text file for a general understanding 
  14.  of the X-Modem file transfer protocol and the terms used in it.
  15.  
  16. New things you need to know beforehand...
  17.  
  18. The following term is just an ASCII code:
  19.  STX = chr(2) = CTRL-B
  20.  
  21. The CRC starts with a value of zero at the beginning of each block.  Now to 
  22.  update the CRC, with each byte in the 1024 byte packet simply do this (the
  23.  oldcrc is the crc value to be updated, data is the current byte):
  24.      CRC:=(oldcrc shl 8) xor (crctable[(oldcrc shr 8) xor data]);
  25. The final value of the CRC (after all 1024 bytes) is what is being sent in 
  26.  the X-Modem CRC protocol.
  27.  
  28. If a 128 byte packet is sent, the CRC is calculated in the same manner as in
  29.  X-Modem CRC.
  30.  
  31. These are the only new things that are needed in X-Modem 1K. :)
  32.  
  33.  
  34. --- The Actual Transfer ---
  35.  
  36. As in X-Modem, the uploader waits for the downloader to send the NCGbyte.  
  37.  The NCGbyte for X-Modem 1K is identical to the NCGbyte for X-Modem CRC and 
  38.  it is chr(67) or the capital letter C (unlike X-Modem where the NCGbyte is 
  39.  chr(21), the NAK).  If the downloader takes too long or an error occurs then 
  40.  the uploader will stop waiting or "Time Out".  If this happens, then the 
  41.  file transfer must restart.
  42.  
  43. The uploader can send either 1024 byte or 128 byte packets.  1024 byte
  44.  packets are faster but 128 bytes at the end of the transfer can save some
  45.  time at the end.  This is because if there are only 125 bytes left to send,
  46.  only one 128 byte packet would be necessary (in which case you would send
  47.  3 null (chr(0)) bytes) whereas sending a 1024 byte packet would send 999
  48.  nulls.
  49.  
  50. With each packet sent...
  51.  
  52.     In each 1024 byte (1k) packet, the uploader sends:
  53.  
  54.     1. an STX byte                             {1 byte}
  55.     2. the packet number                       {1 byte}
  56.     3. the 1's complement of the packet number {1 byte}
  57.     4. the packet                           {1024 bytes}
  58.     5. the high byte of the CRC-16             {1 byte}
  59.     6. the low byte of the CRC-16              {1 byte}
  60.     
  61.    In each 128 byte packet, the uploader sends:
  62.     
  63.     1. an STX byte                             {1 byte}
  64.     2. the packet number                       {1 byte}
  65.     3. the 1's complement of the packet number {1 byte}
  66.     4. the packet                           {1024 bytes}
  67.     5. the high byte of the CRC-16             {1 byte}
  68.     6. the low byte of the CRC-16              {1 byte}
  69.  
  70.     These six things make up the block.
  71.  
  72.     The downloader:
  73.  
  74.     1. ensures that the packet number sent matches the actual packet number
  75.      that it is (If the third block sent has a '4' as the second byte,
  76.      something is wrong --> CANCEL TRANSFER (send CAN byte))
  77.     2. adds the packet number and the 1's complement of the packet number
  78.      together to make sure that they add up to 255.  if they don't -->
  79.      CANCEL TRANSFER
  80.     3. sets the CRC to zero
  81.     4. updates the CRC as each byte in the packet is sent
  82.     5. compares the calculated CRC to the CRC that is sent
  83.     6. if everything looks ok (calculated CRC=sent CRC), then the downloader
  84.      appends the bytes in the packet to the file being created (sent).
  85.      The downloader then sends an ACK byte which tells the uploader to
  86.      send the next block.
  87.        if the CRCs do not match, then the downloader sends a NAK byte which
  88.      tells the uploader to send the same block it just sent over again.
  89.  
  90. When the uploader sends an EOT byte instead of an SOH or STX byte, the down-
  91.  loader sends a NAK byte.  If the uploader sends another EOT immediately 
  92.  after that, the downloader sends an ACK byte and the transfer is complete.
  93.  
  94. Another thing, the downloader can cancel the transfer at any time by sending
  95.  a CAN byte.  The uploadered can cancel only between blocks by sending a CAN
  96.  byte.  It is recommended that you send between 2 and 8 consecutive CAN bytes
  97.  as some communication programs will not allow you to cancel with only 1 CAN
  98.  byte.
  99.  
  100.  
  101. --- Wrap Up ---
  102.  
  103. Hopefully, you were able to follow along. :)  If not, you can e-mail me at
  104.  em_decay@norlink.net  and I will try to clarify it for you.  Have fun :)
  105.  
  106. Perception:    Em Decay -- Mark Korhonen
  107.            Cmf ------- Chris Fillion
  108.  
  109. Written on Jan.19/95
  110.